Signature key resolution and a send-path leak - #11283
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesRouter packet handling and verification
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
⚡ Try this PR in the Web FlasherWarning This is an automated, unreviewed CI test build. Back up your device configuration Supported boards built by this PR (31)
Build artifacts expire on 2026-08-28. Updated for |
Two follow-ups from the post-release backlog, one commit each. Independent of #11282; both branch from develop and merge cleanly in either order.
checkXeddsaReceivePolicyresolved the sender key withcopyPublicKey, which falls through to the opportunistic TrafficManagement cache. A key planted there could verify a signature and so mark its own node a signer, the trust loop Gate the PKI-decrypt key on signer-proven, not the opportunistic cache #11116 closed on the decrypt path. Now usescopyPublicKeyAuthoritative.Router::sendreturned BAD_REQUEST for a packet with nopayload_variantwithout releasing it, unlike the position-precision path a few lines below. Reachable from a ToRadio MeshPacket with the variant unset.Summary by CodeRabbit